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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in TS 181 002 [1], TS 181 005 [10], 
TS 123 003 [13] and the following apply: 

correspondent: person or entity that deposits messages in the subscriber's message account 

NOTE: Correspondent and subscriber can be the same person or entity. 

Message Account (MA): resource that retains multimedia messages (voice, video, fax, etc.) deposited by 
correspondents for the subscriber 

subscriber: person or entity that receives status information about deposited messages 

supplementary service: modifies or supplements a basic Telecommunication service 

trusted identity: network generated user address information 

untrusted identity: user generated user address information 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

CD Communication session Deflection 

CDIV Communication Diversion 

CFB Communication session Forwarding Busy 

CFNL Communication session Forwarding on No Logged-in 

CFNR Communication Forwarding No Reply 

CFU Communication session Forwarding Unconditional 

CONF CONFerence calling 

CSCF Call Session Control Function 

ECT Explicit Communication Transfer 

HOLD Communication session Hold 

IBCF Interconnection Border Control Function 

I-CSCF Interrogating - CSCF 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

MA Message Account 

MCID Malicious Call IDentification 

MIME Multipurpose Internet Mail Extensions 

MNUA MWl Notifier User Agent 

MSUA MWI Subscriber User Agent 

MWI Message Waiting Indication 

NGN Next Generation Network 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy - CSCF 

PSl Public Service Identity 

PSTN Public Switch Telephone Network 

S-CSCF Serving - CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

THIG Topology Hiding Gateway 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 
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UA 
UE 
URI 



User Agent 

User Equipment 

Universal Resource Identifier 



Message Waiting Indication (IVIWI) 



4.1 



Introduction 



The Message Waiting Indication (MWI) service enables the network, upon the request of a controlling user to indicate 
to the receiving user, that there is at least one message waiting. 

4.2 Description 
4.2.1 General description 

The MWI service enables the application server to indicate to the subscriber, that there is at least one message waiting. 

The indication is delivered to the subscriber's UE after successful subscription to the Message Waiting Indication 
service as described in the present document. 

Other modes of MWI service invocation are not applicable. 

NOTE: Having received this indication, the subscriber user can subsequently access the message account, to have 
the deposited message delivered. The means by which the subscriber accesses and manages the message 
account are outside the scope of the present document. 



4.3 



Functional entities 



4.3.1 User Equipment (UE) 

The UE shall implement the MWI Subscriber User Agent role as described in clause 4.4.1. 

4.3.2 Application Server (AS) 

An application server shall implement the role of a MWI Notifier User Agent as described in clause 4.4.2. 

Application Server can implement the role of the application server (AS) acting as terminating UA as described in 
ES 283 003 [2], clause 5.7.2. 

Additionally an application server may implement other roles for the receipt and storage of the messages for example 
Web Server, Mail Transfer and Delivery Agent, Short Message Service centre, etc. 

The definition of additional roles for an MWI Application Server is out of the scope for the current specification. 



4.4 



Roles 



4.4.1 MWI Subscriber User Agent (MSUA) 

A MWI Subscriber User Agent is an entity that is subscribed or requests information about status change of message 
account from an MWI AS. 

Actions performed by a MWI Subscriber User Agent as a part of the user equipment are described in clause 4.7.2.1. 
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4.4.2 MWI Notifier User Agent (MNUA) 

MNUA is an entity that provides information about changes in message account status to the MSUA. 
Actions performed by a notifier user agent as a part of the application server are described in clause 4.7.2.5. 

4.4.3 Message Account (MA) 

The definition of the message account from the RFC 3842 [3] applies with following additions: 
Message account retains multimedia messages (e.g. voice, video, fax) intended to a particular subscriber. 

4.4.3.1 Identification of the message account for the message deposit 

Since messages may be intended to the different public user identities that belong to the same subscriber, the message 
account may be configured to retain messages for any of the subscriber's public user identities. 

Configuration of a message account to retain messages for each public user identity, for a group of public user identities 
or for all of public user identities that belong to the same subscriber is subject to the operator's policy. 

4.4.3.2 Identification of the message account for the MWI subscription 

For the identification of the message account by subscriptions to the MWI service either a public service identity can be 
assigned to the message account or any of subscriber's public user identity can be used, subject to the operator's policy 
(see examples in clause A. 1.1.2). 

4.5 Operational requirements 

4.5.1 Provision/withdrawal 

The MWI service shall be provided after prior arrangement with the service provider. The MWI service shall be 
withdrawn at the subscriber's request or for administrative reasons. 

Depending on the arrangement with the service provider either any of the subscriber's public user identities or public 
service identity of the message account can be used to access the MWI service, see annex B. 

The subscriber's UE shall be made aware about the option used by service provider to identify access to the MWI 
service. 

4.5.2 Requirements on the originating network side 

No specific requirements are needed on the originating network side. 

4.5.3 Requirements in the network 

No specific requirements are needed in the network. 

4.5.4 Requirements on the terminating network side 

No specific requirements are needed in the network. 



4.6 Coding requirements 



The application/simple-message-summary MIME type used to provide Message Summary and Message Waiting 
Indication Information shall be coded as described in the subclause 5 of RFC 3842 [3]. 

The coding of the message types in the message-context-class values shall follow the rules defined in the specifications 
listed in the "reference" column of table 1. 
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Table 1 : Coding requirements 



Value 


Reference 


voice-message 


RFC 3458 [5] 


video-message 


RFC 3938 [6] 


fax-message 


RFC 3458 [5] 


pager-message 


RFC 3458 [5] 


multimedia-message 


RFC 3458 [51 


text-message 


RFC 3458 [5] 


none 


RFC 3458 [5] 



The coding of the additional information about deposited messages in the appHcation/simple-message-summary MIME 
type body shall be in alignment with the rules defined in subclause 25 of RFC 3261 [11] for SIP extension-header 
(subclause 3.5 of RFC 3842 [3]) and follow the rules defined in the specifications listed in the "reference" column of 
table 2. 

Table 2: Additional information 



Header 


Description 


Reference 


To: 


Indicates the subscriber's public user identity used by correspondent 
to deposit a message. 


subclause 3.6.3 of RFC 2822 [7] 


From: 


Indicates the correspondent's public user identity, if available. 


subclause 3.6.2 of RFC 2822 [7] 


Subject: 


Indicates the topic of the deposited message as provided by 
correspondent. 


subclause 3.6.5 of RFC 2822 [7] 


Date: 


Indicates the time and date information about message deposit. 


subclause 3.6.1 of RFC 2822 [7] 


Priority: 


Indicates the message priority as provided by correspondent. 


RFC 2156 [8] 


IVIessage-ID: 


Indicates a single unique message identity. 


subclause 3.6.4 of RFC 2822 [7] 


IVIessage-Context: 


Indicates a type or context of message. 


RFC 3458 [5] 



4.7 Signalling requirements 

4.7.1 Activation/deactivation/registration 

The MWI service is immediately activated after successful subscription from the subscriber's UE see clause 4.7.2. 

The MWI service is deactivated after subscription expiry or after unsuccessful attempt to deliver a notification about 
message waiting. 

4.7.2 Invocation and operation 

4.7.2.1 Actions at the UE 

When the subscriber user agent intends to subscribe for status information changes of a message account, it shall 
generate a SUBSCRIBE request in accordance with RFC 3265 [4] and RFC 3842 [3] and in alignment with the 
procedures described in ES 283 003 [2]. 

Depending on the service provisioning the UE will address the SUBSCRIBE request either to one of the subscriber's 
public user identities or to the public service identity of the message account (see clause 4.5.1). 

The subscriber's UE shall implement the "application/simple-message-summary" content type as described in 
RFC 3842 [3]. 

4.7.2.2 Actions at the P-CSCF 

Procedures according to ES 283 003 [2] shall apply. 
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4.7.2.3 Actions at the serving S-CSCF 

Procedures according to ES 283 003 [2] shall apply. 

The S-CSCF validates the service profile of the subscriber and evaluates the initial filter criteria. 

Depending on the service provisioning (see clause 4.5.1) the S-CSCF will: 

• either trigger on the "message-summary" event; or 

• perform the public service identity resolution of the message account SIP URI; 
to identify the route to the MWI AS. 

After route identification the S-CSCF processes the SUBSCRIBE request according to ES 283 003 [2]. 

4.7.2.4 Actions at the terminating S-CSCF 

This clause applies if the MWI service is addressed using public service identity, see clause 4.4.3.2. 
Procedures according to ES 283 003 [2] shall apply. 

4.7.2.5 Actions at the AS 

When the Application Server receives a SUBSCRIBE request for the 'message-summary' event package, the 
Application Server shall identify the message account which status information is requested (see clause 4.4.3.2), then 
the AS shall attempt to verify the identity of the source of the SUBSCRIBE request as described in ES 283 003 [2] 
clause 5.7.1.4, then perform authorization according to ES 283 003 [2] clause 5.7.1.5. 

In case of successful subscription, the AS shall generate a response to the SUBSCRIBE request and notifications in 
accordance with RFC 3265 [4] and RFC 3842 [3]. 

4.7.2.6 Actions at the outgoing l-CSCF (THIG) 

Procedures according to ES 283 003 [2] apply. 

4.7.2.7 Actions at the incoming l-CSCF 

Procedures according to ES 283 003 [2] apply. 

4.7.2.8 Actions at the outgoing IBCF 

Procedures according to ES 283 003 [2] apply. 

4.7.2.9 Actions at the incoming IBCF 

Procedures according to ES 283 003 [2] apply. 

4.8 Interaction with other IIVIS capabilities 

4.8.1 Presence 

Interaction of the presence IMS capability and message waiting indication service is for further study. 

4.8.2 Messaging 

Interaction of messaging IMS capability and message waiting indication service is for further study. 
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4.9 Interaction with other services 

4.9.1 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.9.2 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.9.3 Terminating Identification Restriction (TIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.9.4 Originating Identification Presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.9.5 Originating Identification Restriction (OIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.9.6 CONFerence calling (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.9.7 Communication Diversion services (CDIV) 

The subscriber of the message waiting indication service receives the notifications about the change in the status of 
message account only from message waiting indication application server. 

Communication diversion services shall not impact the processing of message waiting indication subscriptions, 
notifications and responses. 

4.9.7.1 Communication Forwarding Unconditional (CFU) 

MWI notifications shall not be affected by the communication forwarding unconditional service and always be 
forwarded to subscribers' current location (if known). 

4.9.7.2 Communication Forwarding Busy (CFB) 

MWI notifications shall not be affected by the communication forwarding busy service and always be forwarded to 
subscribers' current location (if known). 

The UE will inform the AS if it will not be able to process the notification at the time. 

4.9.7.3 Communication Forwarding No Reply (CFNR) 

MWI notifications shall not be affected by the communication forwarding busy service and always be forwarded to 
subscribers' current location (if known). 

The S-CSCF will inform the AS if the UE can not be contacted at the time. 
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4.9.7.4 Communication Forwarding on Not Logged-in (CFNL) 

MWI notifications shall not be affected by the communication forwarding busy service and always be forwarded to 
subscribers' current location (if known). 

The S-CSCF will inform the AS if the UE is not logged-in at the time. 

4.9.7.5 Communication Deflection (CD) 

MWI notifications shall not be affected by the communication deflection service. All the CSCFs and AS shall ignore 
the redirection information received from the UE and proceed a 3xx response as a 480 Temporarily Unavailable 
response. 

4.9.8 Malicious Call Identification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.9.9 Explicit Communication Transfer (ECT) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.1 Interactions with other networks 

Interaction with other networks is performed according to ES 283 003 [2]. 

4.1 0.1 Interworking with the PSTN/ISDN 

Interworking of the SIP based MWI service with ISDN MWI service is for further study. 

4.1 0.2 Interaction with PSTN/ISDN Emulation 

Interworking of the SIP based MWI service with the emulation MWI service is for further study. 

4.10.3 Interaction with external IP networks 

Interaction with external IP networks are performed according to ES 283 003 [2]. 

4.1 1 Parameter values (timers) 

Not applicable. 
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Annex A (informative): 

Example signalling flows of Message Waiting Indication 

(MWI) service operation 



A.1 Scope of signalling flows 



This annex gives examples of signalling flows for the Message Waiting Indication service within the TISPAN 
PSTN/ISDN Simulation subsystem based on the Session Initiation Protocol (SIP). 

A. 1.1 Introduction 
A. 1.1.1 General 

The signalling flows provided in the following clauses follow the methodology developed in TS 124 228 [12]. The 
following additional considerations apply. 

A.I .1 .2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in TS 124 228 [12] clauses 4.1 and 4.2 applies with the additions 
specified below: 

mwi.homel.net: an MWI AS in the home network of the service provider; 

userl_mwiaccl@homel.net: public service identity of the message account; 

userl_publicl@homel.net: first subscriber's public user identity assigned to the message account; 

userl_public2@homel.net: second subscriber's public user identity assigned to the message account; 

user2_publicl@home2.net: first correspondent of messages in the message account; 

user3_publicl @home3.net: second correspondent of messages in the message account. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in TS 124 228 [12]. 

However, TS 124 228 [12] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
TS 124 228 [12], then such text is not reproduced in the present document. 

Headers following the tables that are represented in fat cursive style describe the contents of the application/simple- 
message-summary MIME body. 

Additional text may also be found on the contents of headers within TS 124 228 [12] in addition to the material shown 
in the present document. 

A.I .2 Signalling flows demonstrating how UE subscribes to 
message waiting indication event notification 

A.I. 2.1 Introduction 

The clause covers the signalling flows that show how UE can request message waiting indication information from an 
application server. 
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A.1 .2.2 MWI Subscriber subscribing to tine status of Inis message account, 
MWI AS is in tine subscriber's network 

Successful subscription, UE in visited network. This example shows the case when the originating S-CSCF, routes the 
SUBSCRIE request to an AS that provides the MWI service, based on the resolution of the public service identity of the 
message account. 

For the purpose of the subscriber's identity verification, the AS is located within the same trusted domain as the 
subscriber, see ES 283 003 [2] clause 5.7.1.4. 









r 






UE 
(Subscriber) 






P-CSCF 




S-CSCF 




1. SUBSCRIBE 














2. SUBSCRIBE 
















3. EvalL 

initia 

crit 


ation of 
filter 
aria 



7. 200 (OK) 



8. 200 (OK) 



10. NOTIFY 



11. NOTIFY 



12. 200 (OK) 



13. 200 (OK) 



17. NOTIFY 



18. NOTIFY 

19. 200 (OK) 



20. 200 (OK) 



Subscriber's Home Network 



4. SUBSCRIBE 



6. 200 (OK) 



9. NOTIFY 



14. 200 (OK) 



16. NOTIFY 



21. 200 (OK) 



AS(MWI) 



5. Subscriber 
Autfiorisation 



15. notifications on 

message-summary 

event package 



Figure A.I : UE subscription for the message-summary event pacltage 

Figure A. 1 shows a user equipment subscribing to the message waiting indication notification. The details of the 
signalling flows are as follows: 

1 . SUBSCRIBE request (UE to P-CSCF) - see example in table A.l 



A subscriber agent in a UE wishes to receive message waiting indication information from an application 
server. To initiate a subscription, the UE generates a SUBSCRIBE request containing the 
"message-summary" event that it wishes to be notified of, together with an indication of the length of 
time this periodic subscription should last. 
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Table A.1 : SUBSCRIBE request (UE to P-CSCF) 



SUBSCRIBE sip: userl_mwiaccl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP 1 . 2 . 3 . 4 : 1357;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl.visitedl.net:7531;lr;>, <sip:orig@scscfl. homel . net ; lr> 

P-Preferred- Identity: <sip: userl_publicl@homel . net> 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=31415 

To : <sip : userl_mwiaccl@homel . net> 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 61 SUBSCRIBE 

Event: message-summary 

Expires: 7200 

Accept : application/simple-message-summary 

Contact: <sip:userl_publicl@l . 2 . 3 . 4 : 1357> 

Content-Length: 



Request URI: Public service identity of the message account whose events the subscriber subscribes to. In this 
case the subscriber subscribes to the message waiting indication events. 

Event: This field is populated with the value "message-summary" to specify the use of the Message 

Summary Package. 

Accept: This field is populated with the value "application/simple-message-summary" as described in 

RFC 3842 [3]. 



To: 

2. 



Same as the Request-Uri. 
SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A.2 

The SUBSCRIBE request is forwarded to the I-CSCF. 

The P-CSCF looks up the serving network information for the public user identity that was stored during 
the registration procedure. The SUBSCRIBE request is forwarded to S-CSCF#1. A Route header is 
inserted into SUBSCRIBE request. The information for the Route header is taken from the service route 
determined during registration. 



Table A.2: SUBSCRIBE request (P-CSCF to S-CSCF) 



SUBSCRIBE sip:userl_mwiaccl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net;branch=z9hG4bK120f 34 . 1, SIP/2. 0/UDP 

1.2.3.4:1357; comp=sigcomp; branch=z9hG4bKehuef dam 
P-Access-Network-Inf o : 

Route : <sip:orig@scscfl. homel .net; lr> 
Max-Forwards: 6 9 

P-Asserted-Identity : <sip : userl_publicl@homel . net> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=22 355102 4" 
Privacy : 

Record-Route : <sip:pcscfl. visitedl. net ;lr> 
Route : <sip:scscfl. homel .net; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Event : 
Supported: 
Expires : 
Accept : 
Contact : 
Content-Length : 
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Evaluation of initial filter criteria 



The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 
Assuming that sip:userl_mwiaccl @homel.net is a statically created PSI, 

sip:userl_mwiacc l@homel.net is included in the service profile ofuserl_publicl@homel.net as part of 
an originating initial Filter Criteria with Service Trigger Point of Method = SUBSCRIBE AND Event = 
"message-summary" AND Request-URI = sip:userl_mwiaccl@homel.net, that informs the S-CSCF to 
route the SUBSCRIBE request to the application server sip:mwi. ho mel.net. 

If there is no initial filter criteria for this PSI (sip:userl_mwiaccl@homel.net), the assumption is that the 
PSI is a sub domain-based PSI. The procedure defined in RFC 3263 [9] with DNS NAPTR and SRV 
queries aligned with the operator policy may then be used for the resolution of the PSI. 

4. SUBSCRIBE (S-CSCF to AS) - see example in table A.3 

The S-CSCF forwards the SUBSCRIBE request to AS. 

Table A.3: SUBSCRIBE request (S-CSCF to AS) 



SUBSCRIBE sip : user l_mwiaccl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK344a65 . 1 , SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK120f 34 .1, SIP/2 .0/UDP 

1.2.3.4: 1357; branch=z9hG4bKehuefdam 
Max-Forwards: 68 

P-Asserted-Identity : <sip :userl_publicl@homel .net>, <tel :+l-212-555-llll> 
P-Charging-Vector : 
P-Charging-Function-Addresses : 
Privacy : 

Record-Route : <sip:orig@scscfl. homel .net; lr>, <sip :pcscfl .visitedl .net; lr> 
Route: <sip :mwi .homel .net; lr>, <sip : orig@scscfl .homel .net; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Event : 
Supported: 
Expires : 
Accept : 
Contact : 
Content-Length : 



5. Identification of the message account and subscriber authorization 

Based on the Request-URI the MWI AS identifies the requested message account. 

P-Asserted-Identity header information authorizes the subscriber to subscribe to status change of the 
message account, as one of the identities is authorized for this account. 

In this example the authorization is successful, so the AS sends a 200 (OK) response to the S-CSCF. If 
the previous condition failed, then a 403 (Forbidden) response would be sent to the S-CSCF. 

6. 200 (OK) response (MWI AS to S-CSCF) - see example in table A.4 

The MWI AS forwards the response to the S-CSCF. 
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Table A.4: 200 (OK) response (AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2 .0/UDP scscfl .homel .net;branch=z9hG4bK34 4a65 . 1, SIP/2 .0/UDP 

pcscfl. visitedl.net ;branch=z9hG4bK120f 34. 1, SIP/ 2. 0/UDP 

1.2.3.4: 1357; branch=z9hG4bKehuef dam 
P-Charging-Vector : icid-value="AyretyU0dm+6O2lrT5tAFrbHLso=22 355102 4 " ; orig-ioi=homel . net ; 

term-ioi=homel . net 
Record-Route : 

From: <sip : userl_publicl@homel . net>; tag=31415 
To : <sip : u serl_mwi ace 1@ homel . net>; tag=151170 
Call-ID: b8 9r jhnedlrf jflsl j4 0a222 
CSeq: 
Expires : 

Contact : <sip :mwi . homel . net> 
Content-Length: 



7. 200 (OK) response (S-CSCF to P-CSCF ) 

The S-CSCF forwards the 200 OK response to the P-CSCF. 

8. 200 (OK) response (P-CSCF to UE) 

P-CSCF forwards the 200 OK response to the UE. 

9. NOTIFY request (MWI AS to S-CSCF) - see example in table A.5 

As required by the RFC 3265 [4] the MWI AS immediately after successful subscription sends the 
NOTIFY request to the S-CSCF to synchronize the current state of the message account at the 
subscriber's UE. This initial notification contains no extended information about available message. 
Further notifications sent by MWI AS may contain either extended or basic set of message waiting 
information as described in RFC 3842 [3]. 

In this example it is assumed that the message account at the moment of subscription has thee voice 
messages (two new and one old, with one new message being urgent), one old video message and two 
fax messages (one new and one old with the old message being urgent). 

Table A.5: Initial NOTIFY request (MWI AS to S-CSCF) 

NOTIFY sip:userl_publicl@1.2.3.4: 1357 SIP/2.0 

Via: SIP/2. 0/UDP mwi .homel . net; branch=z9hG4bK332b23 . 1 

Max-Forwards; 70 

Route; <sip; scscfl .homel . net; lr>, <sip;pcscfl .homel . net; lr> 

From; <sip ; userl_mwiaccl@homel .net>;tag=31415 

To ; <sip ; userl_publicl@homel .net>;tag=151170 

Call- ID; b8 9r jhnedlrf jflsl J40a222 

CSeq; 42 NOTIFY 

Subscript ion- St ate ; active; expires=7200 

Event; message-summary 

Contact; <sip;mwi .homel . net> 

Content-Type ; application/simple-message-summary 

Content-Length; (...) 

Messages-Waiting; yes 

Message-Account ; sip ; userl_mwiaccl@homel . net 

Voice-Message; 2/1 (0/0) 

Video-Message; 0/1 (0/0) 

Fax-Message; 1/1 (0/1) 

Content-Type: Set to "application/simple-message-summary" as described in RFC 3842 [3]. 

The message body in the NOTIFY request that carries the message waiting indication is formed as described in 
clause 4.6. 

Message-Account: The MWI AS populates this filed with the public service identifier of the message account 

that received the subscription. 

Voice-Message: The MWI AS populates this filed with the information about voice messages that are 

waiting in the message account. 
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Video-Message: The MWI AS populates this filed with the information about video messages that are 

waiting in the message account. 

Fax-Message: The MWI AS populates this filed with the information about fax messages that are waiting 

in the message account. 

12. 200 (OK) response (UE to P-CSCF) 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

15. notifications on message-summary event package 

After the MWI AS generated a NOTIFY request to inform the subscriber's UE about the subscription 
state, the MWI AS waits for the change of the message account status. As soon as new messages(s) are 
deposited into the message account the MWI AS generates a NOTIFY request to indicate the change in 
the message account status to the subscriber's UE. 

16. NOTIFY request (AS to S-CSCF) - see example in table A.6 

The MWI AS uses available information from the interaction with correspondents and message left in the 
message account to fill the headers in the simple-message-summary MIME body of the NOTIFY request. 
This notification sent by the MWI AS contains an extended set of message waiting information about 
newly deposited messages since the last notification as described in RFC 3842 [3]. 

In this example it is assumed that the subscriber's message account has received three new messages (two 
urgent voice and one non urgent video message) since the successful immediate NOTIFY transaction 
from the correspondents sip: user2_publicl@homel.net and sip:user3_publicl@home3.net. The 
correspondents used different public user identities of the subscriber to deposit messages. 

Table A.6: NOTIFY request (MWI AS to S-CSCF) 

NOTIFY sip:userl_publicl@1.2.3.4: 1357 SIP/2.0 

Via: SIP/2. 0/UDP mwi . homel . net ; branch=z9hG4bK332b23 . 1 

Max-Forwards; 70 

Route: <sip: scscfl .homel . net; lr>, <sip;pcscfl .homel . net; lr> 

From: <sip:userl_ mwiacc l@homel . net>; tag=31415 

To : <sip:userl_publicl@homel . net>; tag=151170 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 43 NOTIFY 

Subscription-State : active; expires=5000 

Event: message-summary 

Contact: <sip :mwi . homel . net> 

Content-Type : application/simple-message-summary 

Content-Length: (...) 

Messages-Waiting: yes 

Mess age -Ac count : sip : userl_mwiaccl@homel .net 

Voice-Message: 4/1 (2/0) 

Video-Message: 1/1 (0/0) 

Fax-Message: 1/1 (0/1) 

To: <userl_publicl(3homel . net> 

From: <user2_publicl(3homel . net> 

Subject: call me back! 

Date: 19 Apr 2005 21:45:31 -0700 

Priority: urgent 

Message- ID: 277753344 85@mwi.homel.net 

Message-Context: voice-message 

To: <userl_public2(3homel . net> 

From: <user2_publicl(?homel . net> 

Subject: Where are you that late??? 

Date: 19 Apr 2005 23:45:31 -0700 

Priority: urgent 

Message- ID: 277753344 85@mwi.homel.net 

Message-Context: voice-message 

To: <userl_publicl@homel . net> 
From: <user3_publicl@home3 . net> 
Subject: Did you see that penalty! ! ! 
Date: Tue, 19 Apr 2005 22:12:31 -0700 
Priority: normal 
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Message- ID: 2 67753344 85@mwi.homel.net 
Message-Context: video-message 



Content-Type: 



Set to "application/simple-message-summary" as described in RFC 3842 [3]. 



The message body in the NOTIFY request that carries the message waiting indication is formed as described in the 
clause 4.6. 



Message-Account: 
Voice-Message: 

Video-Message : 

Fax-Message: 

To: 

From: 

Subject: 

Date: 
Priority: 

Message-ID: 

Message-Context: 



The MWI AS populates this filed with the public service identifier of the message account 
that has new messages for the subscriber. 

Since two new urgent voice messages were received by the message account, the number of 
new voice messages is increased to four and the number of the new urgent messages is 
increased to two. 

One new video message was received by the message account and accordingly the number 
of new video messages set to one. 

No new fax messages were received by the message account, so the number of fax 
messages is unchanged. 

This header in the MIME body populate the information about the public user identity of 
subscriber, that was used by correspondent to deposite a message. 

This header in the MIME body populate the information about the public user identity, of 
correspondent, that left a message to the subscriber. 

This header populates the information about the subject, that was assigned to the left 
message by correspondent. 

This header populates the information about the date and time when a message was left. 

This header populates the information about the message urgency assigned by 
correspondent. 

This header populates the information about the message identity, that is assigned to the 
message by the MWI AS. 

This header populates the information about the type of the deposited message, that has the 
extended set of message waiting information. 



A.1 .2.3 MWI AS notifying tine subscriber about cinanges in tine status of 
message account 



This example shows the case when the message waiting indication service was invoked by the subscription to one of the 
subscriber's public user identities. 

MWI AS notifies subscriber's UE about new message being deposited into the subscribers message account. 
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UE 

(Subscriber) 



Visited Netwo* 

P-CSCF S-CSCF 



Subscriber's Home Networl< 



3. NOTIFY 



4. NOTIFY 



5. 200 (OK) 



6. 200 (OK) 



AS(MWI) 



1 . notifications on 

message-summary 

event pacl^age 



2. NOTIFY 



7. 200 (OK) 



Figure A.2: Notification of change in the status of message account 
Table A.7: NOTIFY request (MWI AS to S-CSCF) 



NOTIFY sip:userl_publicl@1.2.3.4: 1357 SIP/2.0 

Via: SIP/2. 0/UDP mwi . homel . net ; branch=z9hG4bK332b43 . 1 

Max-Forwards; 70 

Route; <sip; scscfl .homel . net; lr>, <sip;pcscfl .homel . net; lr> 

From; <sip;userl_ publicl@homel . net>; tag=53254 

To ; <sip;userl_publicl@homel . net>; tag=34533 

Call-ID; sdf243dsaf323fdswf23r 

CSeq; 32 NOTIFY 

Subscription-State ; active; expires=3000 

Event; message-summary 

Contact; <sip;mwi .homel . net> 

Content-Type ; application/simple-message-summary 

Content-Length; (...) 



A.1 .3 Signalling flows demonstrating how AS sends message 
waiting indication notification to the UE which does not 
implement RFC 3842 

A.1.3.1 Introduction 

The clause covers the signalHng flows that show how MWI AS sends message waiting indication information to the UE 
which does not implement RFC 3842 [3]. 
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A.1 .3.2 Registration signalling for MWI subscriber 

This example shows the registration signalling for MWI subscriber: 



UE 
(Subscriber) 



Visited Networi< 

P-CSCF 



Subscribers Home Networl< 



S-CSCF 



REGISTER 



2 REGISTER 



3 200 (OK; 



4 200 (OK; 



5 Evaluation of initial 
filter criteria 



1C MESSAGE 



1- MESSAGE 

12 200 ( ok; 



13 200 (OK; 



6 REGISTER 



7 200 (OK; 



9 MESSAGE 



14 200 ( ok; 



AS(MWI) 



8 Update subscriber 

registered state if UE 

registered state cliange 

to registered send MWI 

MESSAGE to UE 



Figure A.3: Registration signalling for MWI subscriber 

When the MWI subscriber registered state changes, e.g. initiate the register procedure, S-CSCF evaluates the initial 
filter criteria, initiate a third party registration procedure by send REGISTER request to MWI AS. The MWI AS may 
also subscribe to the reg event package for the public user identity registered at the users registrar (S-CSCF) to receive 
the subscriber's registration state information, see ES 283 003 [2], clause 5.7.1.1. 

The details of the signalling flows are followed: 

1 . REGISTER request (UE to P-CSCF) - see example in table A.8. 

The purpose of this request is to register the user's SIP URI with a S-CSCF in the home network. This 
request is routed to the P-CSCF. 

Table A.8: REGISTER request (UE to P-CSCF) 

REGISTER sip:homel.net SIP/2.0 

Via: SIP/2. 0/UDP 1 . 2 . 3 . 4 : 1357; branch=z9hG4bKnashds7 

Max-Forwards; 70 

Route ; <sip;pcscfl .visitedl . net ; 7531; Ir; > 

From: <sip ; userl_publicl@homel .net>;tag=31415 

To ; <sip ; userl_publicl@homel . net> 

Contact: <sip:userl_publicl@l . 2 . 3 . 4 : 1357> 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 61 REGISTER 

Content-Length: 

2. REGISTER request (P-CSCF to S-CSCF) - see example in table A.9 

P-CSCF forwards the REGISTER to the S-CSCF in MWI subscriber's home network through I-CSCF. 
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Table A.9: REGISTER request (P-CSCF to S-CSCF) 



REGISTER sip:homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bkl20f 34 . 1 

Via: SIP/2. 0/UDP 1 . 2 . 3 . 4 : 1357; branch=z9hG4bKnashds7 

Route : <sip:orig@scscfl. homel . net> 

Max-Forwards: 68 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; > 

From: <sip : userl_publicl@homel . net>; tag=31415 

To : <sip:userl_publicl@homel . net> 

Contact: <sip:userl_publicl@l . 2 . 3 . 4 : 1357> 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 61 REGISTER 

Content-Length: 



3. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.IO. 

S-CSCF authorizes the REGISTER request and send 200 (OK) to P-CSCF. 

Table A.IO: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 








Via: 


SIP/2. 0/UDP pcscfl. visit 


edl. 


net 


;branch=z9hG4bkl20f34.1 


Via: 


SIP/2. 0/UDP 1.2.3.4:1357 


; branch 


=z9hG4bKnashds7 


From 


<sip : userl_publicl@home 


1 . ne 


t>; 


tag=31415 


To: <sip : userl_publicl@homel . 


net> 


; ta 


g=kotimaaa 


Contact: <sip:userl_publicl@l 


.2.3 


.4: 


1357> 


Call- 


-ID: b89rjhnedlrf jflslj40 


a222 






CSeq 


61 REGISTER 








Content-Length: 









4. 200 (OK) response (P-CSCF to UE) 

P-CSCF forwards the 200 OK response to the UE. 

5. Evaluation of initial filter criteria 

After subscriber register to the S-CSCF successfully, S-CSCF will get the service profile of subscriber 
from USPF and evaluates the initial filter criteria. 

For the MWI subscriber, S-CSCF will initiate a third party registration procedure to the AS. 

6. REGISTER request (S-CSCF to AS) - see example in table A.ll 

The purpose of this request is to notify the registered status to the AS. 

Table A.11 : REGISTER request (S-CSCF to AS) 



REGISTER sip: mwi.homel.net SIP/2.0 

Via: <sip:scscfl. homel .net>;branch=99sctb 

Max-Forwards: 70 

From: <sip: scscfl . homel . net>; tag=31415 

To : <sip : userl_publicl@homel . net> 

Contact: <sip: scscfl .homel . net> 

Call-ID: las22kdoa45siewrf 

CSeq: 85 REGISTER 

Content-Length: 



7. 200 OK response (AS to S-CSCF) - see example in table A.12 

AS receive the REGISTER request from S-CSCF and send the 200 OK response to S-CSCF. 
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Table A.12: REGISTER request (AS to S-CSCF) 

SIP/2.0 200 OK 

Via: <sip:scscfl .homel . net>; branch=99sctb 

Max-Forwards: 70 

From: <sip: scscfl . homel . net>; tag=31415 

To : <sip : userl_publicl@homel . net> 

Contact: <sip: scscfl .homel . net> 

Call-ID: las22kdoa45siewrf 

CSeq: 85 REGISTER 

Content-Length: 

8. AS updates the MWI subscriber registered state 

AS updates the MWI subscriber registered state. 

If MWI subscriber registered state changes to registered, AS sends the MWI notification to UE. 

9. MESSAGE request (MWI AS to S-CSCF) - see example in table A.13 

In this example it is assumed that the message account at the moment of registration has three voice 
message, one old video message and two fax messages. 

Table A.13: MESSAGE request (MWI AS to S-CSCF) 

MESSAGE sip:userl_publicl@1.2.3.4: 1357 SIP/2.0 

Via: SIP/2. 0/UDP mwi .homel . net; branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route: <sip: scscfl .homel . net; lr>, <sip:pcscfl .homel . net; lr> 

From: <sip : userl_mwiaccl@homel .net>;tag=31415 

To : <sip:userl_publicl@homel . net>; tag=151170 

Call- ID: b8 9r jhnedlrf jflslj40a222 

CSeq: 42 MESSAGE 

Content-Type: text/plain 

Content-Length: (...) 

You Have new messages on sip : userl_mwiaccl@homel . net ! 

2 Voice-Messages, 1 Video-Messages, 1 Fax-Message in your mailbox, 

to get detail, please visit sip :mwi . homel . net . 

Content-Type: Set to "text/plain" as described in RFC 3428. 

The message body in the MESSAGE request that carries the message waiting indication information in pure text 
format. 

12. 200 (OK) response (UE to P-CSCF) 

The UE acknowledges the MESSAGE request with a 200 (OK) response to the P-CSCF. 

A.1 .3.3 AS notify subscriber winen message account state cinange 

This example shows the case AS notify subscriber changes in the status of message account. 
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Figure A.4: AS notify IVIWI subscriber when message account state change 

When the message account state changes, AS sends the message waiting indication to the UE. 
The details of the signalling flows are followed: 

1 . Message Account state change 

When new message is deposited into the subscribers message account, the Message Account state is 
changed. 

2. AS check MWI subscriber registered state 

AS check the MWI subscriber registered state, if the subscriber is registered, AS will send the message 
waiting indication to the UE. 

3 . MESSAGE request (MWI AS to S-CSCF) - see example in table A.14 

AS sends the message waiting indication to UE. 

Table A.14: IVIESSAGE request (lUIWI AS to S-CSCF) 

MESSAGE sip:userl_publicl@1.2.3.4: 1357 SIP/2.0 

Via: SIP/2. 0/UDP mwi .homel . net; branch=z9hG4bK332b23 . 1 

Max-Forwards; 70 

Route; <sip; scscfl .homel . net; lr>, <sip;pcscfl .homel . net; lr> 

From; <sip ; userl_mwiaccl@homel .net>;tag=31415 

To ; <sip;userl_publicl@homel . net>; tag=151170 

Call- ID; b8 9r jhnedlrf jflslj40a222 

CSeq; 42 MESSAGE 

Content-Type; text/plain 

Content-Length; (...) 

You Have new messages on sip;userl_mwiaccl@homel . net ! 

1 new Voice-Messages in your mailbox, 

to get detail, please visit sip ;mwi . homel . net . 

6. 200 OK response (UE to P-CSCF) 

The UE acknowledges the MESSAGE request with a 200 (OK) response to the P-CSCF. 
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A.1 .4 Signalling flows demonstrating how a message is deposited 
into the subscribers message account 

A.1.4.1 Introduction 

The clause covers the signalhng flows that show how a message is deposited into the subscribers message account. 

A.1 .4.2 Depositing a message into the subscriber's message account 
A.1 .4.2.1 Successful message deposit into the subscriber's message account 

This call-flow shows the deposit of the message in to the subscriber's message account by a correspondent. 
"Integration of resource management and SIP" not required by the MWI AS and not used by correspondent's UE. 
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Figure A.5: Correspondent depositing a message into the subscriber's IVIA 
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Figure A.5 shows a correspondent user equipment creating, interacting over RTP and terminating a session with the 
MWI AS. The details of the signalling flows are as follows: 

1 . INVITE request (Correspondent to P-CSCF) - see example in table A.15 

A correspondent wishes to initiate a session with the MWI subscriber. To initiate the session, the 
correspondent generates an INVITE request to MWI subscriber. 

Table A.15: INVITE request (UE to P-CSCF) 

INVITE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP 2 . 3 . 4 . 5 : 2468; branch=Ouetb 

Max-Forwards; 70 

Route ; <sip;pcscfl.visited2.net;8642;lr;>, <sip;orig@scscfl. home 3 .net; lr> 

P-Preferred- Identity; <sip; user3_publicl@home3 . net> 

Privacy; none 

From; <sip ; user3_publicl@home3 . net>; tag=31417 

To ; <sip;userl_publicl@homel . net> 

Call-ID; apb03a0s09dkjdfglk49111 

CSeq; 22 INVITE 

Contact; <sip ; user3_publicl@2 . 3 . 4 . 5 ; 24 68> 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=user3 2890844526 2890844526 IN IP4 2.3.4.5 

s=- 

c=IN IP4 2.3.4.5 

t = 

m=audio 4 9172 RTF/AVP 

a=rtpmap;0 PCMU/8000 

Request URI: Public user identity of the MWI subscriber. 

From: Public user identity of the Correspondent. 

To: Same as the Request-Uri. 

Content-Type: Set to "application/sdp". 

The message body includes the SDP information. 

2. INVITE request (P-CSCF to S-CSCF) - see example in table A.16 

The INVITE request is forwarded to the S-CSCF in MWI subscriber's home network. 

Table A.16: INVITE request (S-CSCF to S-CSCF) 



INVITE sip: user l_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .home3 .net;branch=z9bhksl3dlc23xm 

Via: SIP/2. 0/UDP pcscf 1 . visited2 . net ; branch=z9hG4bK120f 34 . 1 

Via: SIP/2 .0/UDP 2.3.4 . 5 : 24 68; comp=sigcomp; branch=z9hG4bKehuef dam 

Record-Route : <sip:orig@scscfl. home 3 .net; lr> 

Record-Route : <sip :pcscfl .visited2 .net : 8642; lr> 

Max-Forwards: 68 

Privacy: none 

From: <sip : user3_publicl@home2 . net>; tag=31417 

To : <sip : userl__publicl@homel . net> 

Call-ID: apb03a0s09dkjdfglk49111 

CSeq: 22 INVITE 

Contact: <sip :user3„publicl@2 .3.4.5:2468> 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=user3 2890844526 2890844526 IN IP4 2.3.4.5 

s=- 

c=IN IP4 2.3.4.5 

t = 

m=audio 4 9172 RTF/AVP 

a=rtpmap:0 PCMU/8000 
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3. Evaluation of initial filter criteria 



The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 
Assuming that MWI service is included in the service profile ofuserl_publicl@homel.net as part of an 
terminating initial Filter Criteria with Service Trigger Point of Method = INVITE AND Request-URI = 
sip:userl_publicl @homel.net AND subscriber state = logout, that informs the S-CSCF to route the 
INVITE request to the application server sip:mwi. homel.net when the state of 
userl publicl@homel.net is logout. 

4. INVITE (S-CSCF to AS) - see example in table A.17 

The S-CSCF forwards the INVITE request to AS. 

Table A.17: INVITE request (S-CSCF to AS) 



INVITE sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9ack2k2b jbmOfu 

Via: SIP/2. 0/UDP scscf 1 . home3 . net ; branch=z9bhksl3dlc23xm 

Via: SIP/2. 0/UDP pcscf 1 . visited2 . net ; branch=z9hG4bK120f 34 . 1 

Via: SIP/ 2 .0/UDP 2.3.4 . 5 : 24 68; comp=sigcomp; branch=z9hG4bKehuef dam 

Record-Route : <sip:scscfl. homel .net; lr> 

Record-Route : <sip:orig@scscfl. home 3 .net; lr> 

Record-Route : <sip:pcscfl . visited2 .net : 8 642; lr> 

Max-Forwards: 67 

Privacy: none 

From: <sip : user3_publicl@home2 . net>; tag=31417 

To : <sip : userl_publicl@homel . net> 

Call-ID: apb03a0s09dkjdfglk49111 

CSeq: 22 INVITE 

Contact: <sip :user3_publicl@2 .3.4.5:2468> 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=user3 2890844526 2890844526 IN IP4 2.3.4.5 

s=- 

C=IN IP4 2.3.4.5 

t = 

m=audio 49172 RTF/AVP 

a=rtpmap:0 PCMU/8000 



5. Identification of the message account and subscriber authorization 

Based on the Request-URI the MWI AS identifies the requested message account. 

In the requested message account is valid, AS sends a 200 (OK) response to the S-CSCF. 

6. 200 (OK) response (MWI AS to S-CSCF) - see example in table A.18 

The MWI AS forwards the response to the S-CSCF. 
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Table A.18: 200(OK) response (AS to S-CSCF) 



SIP/2.0 200 OK 



Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9ack2k2b jbmOfu 

Via: SIP/2. 0/UDP scscf 1 . home3 . net ; branch=z9bhksl3dlc23xm 

Via: SIP/2. 0/UDP pcscf 1 . visited2 . net ; branch=z9hG4bK120f 34 . 1 

Via: SIP/ 2 .0/UDP 2.3.4 . 5 : 24 68; comp=sigcomp; branch=z9hG4bKehuef dam 



r> 



Record-Route : <sip:scscfl. homel .net; lr> 
Record-Route : <sip:orig@scscfl. home 3 .net; lr> 
Record-Route : <sip :pcscfl .visited2 .net : 8642; 1 
From: <sip : user3_publicl@home2 . net>; tag=31417 
To : <sip : userl_publicl@homel . net> 
Call-ID: apb03a0s09dkjdfglk49111 
CSeq: 22 INVITE 

Contact: <sip: userl_mwiaccl@mwi . homel . net> 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=user3 2890844527 2890844527 IN IP4 12.13.14.15 

s=- 

c=IN IP4 12.13.14.15 

t=0 

m=audio 345 6 RTF/AVP 

a=rtpmap:0 PCMU/8000 



The Content-Type is set to "application/sdp" and the SDP information in AS in included in the message body. 
9. ACK (Correspondent to P-CSCF) - see example in table A.19 

The correspondent sends an ACK to P-CSCF. 

Table A.19: ACK (UE to P-CSCF) 



ACK sip:userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP 2 . 3 . 4 . 5 : 2468; branch=0uetb 

Max-Forwards: 70 

Route : <sip:pcscfl.visited2.net:8642;lr;>, <sip:orig@scscfl. home 3 .net; lr> 

From: <sip : user3_publicl@home3 .net>;tag=31417 

To : <sip:userl_publicl@homel . net> 

Call-ID: apb03a0s09dkjdfglk49111 

CSeq: 22 ACK 

Content-Length: 



12. The Correspondent deposits a message to the message account 

The correspondent interacts with MWI AS and deposits a message via RTF into the subscriber's message 
account. 

13. BYE request (Correspondent to P-CSCF) - see example in table A.20 

After deposits a message to the subscriber's message account successfully, the correspondent sends a 
BYE to release the session. 

Table A.20: BYE request (UE to P-CSCF) 
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16. 200 (OK) response (MWI AS to S-CSCF) - see example in table A.21 

The MWI AS forwards the response to the S-CSCF. 
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Table A.21 : 200 OK response (AS to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP 2 . 3 . 4 . 5 : 2468; branch=Ouetb 

Max-Forwards; 70 

Route ; <sip:pcscfl.visitecl2.net;8642;lr;>, <sip;orig@scscfl. home 3 . net ; lr> 

From: <sip : user3_publicl@home3 . net>; tag=31417 

To : <sip:userl_publicl@homel . net> 

Call-ID: apb03a0s09dkjdfglk49111 

CSeq: 22 BYE 

Content-Length: 

19. Status of subscriber's MA gets modified 

The MWI AS updates the status of the subscriber's message account. 

If the MWI service is already invoked by the subscriber, MWI notifies the subscriber about new message 
being deposited into the subscriber's message account as described in A. 1.2. 3. 
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Annex B (informative): 
Example of a filter criteria 

The following text is to be used when appropriate. 



This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 

Following example shows the Service Point Triggers in an Initial Filter Criteria of the service profile for the subscriber 
with the public user identity userl publicl@homel.net . This Initial Filter Criteria informs the S-CSCF to route the 
SUBSCRIBE request to the application server sip:mwi. homel.net that provides MWI service addressed with the pubUc 
service identity sip:userl_mwiaccl@homel.net. 

Method: SUBSCRIBE 

Event: message-summary 

Request-URI: sip:userl_m wiaccI@homel.net 

Application Server: sip:mwi. homel.net 

Another example shows the Service Point Triggers in an Initial Filter Criteria of the service profile for the subscriber 
with the public user identity userl publicl@homel.net . This Initial Filter Criteria informs the S-CSCF to route the 
SUBSCRIBE request to the application server sip:mwi.homel.net that provides MWI service addressed with the public 
user identity sip:userl_userl_pubUcI @homel.net. 

Method: SUBSCRIBE 

Event: message-summary 

Request-URI: sip:userl_publicl @homel.net 

Application Server: sip:mwi. homel.net 
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